Tests are broken and the code needs re-organising, but this works, which is very promising.

This is neat. NextJS serialises the project and workflows data as JSON, then requests
http://localhost.zooniverse.org:3000/_next/data/pKc0Nl5BF0VaThy5N0Po4/projects/darkeshard/engaging-the-crowds-2020.json
when you visit the home page from the Classify page.

I'm hoping #1823 will make things cleaner by moving the common page props, like the project, into a shared function. However, with NextJS 9.3 and up, we're going to have to add functions to individual pages. It's probably a good idea to keep those functions short. I wasn't sure how to test the page props here, without just duplicating the fetchWorkflowsHelper tests.

I've tidied up getting the page props from the request. #1823 should allow us to replace the duplicated project fetch (once in getInitialProps and once here) with something like:

const { env } = query
const { props: defaultProps } = await getDefaultPageProps({ params, query, req, res })
const language = defaultProps.initialState.project.primary_language
const { active_workflows, default_workflow } = defaultProps.initialState.project.links
const workflows = fetchWorkflowsHelper(language, active_workflows, default_workflow, env)
const props = Object.assign({}, { workflows }, defaultProps)
return { props }

For the content pages app, I've experimented with putting the page data fetching functions under /src/screens:
https://github.com/zooniverse/front-end-monorepo/blob/master/packages/app-content-pages/src/screens/Publications/getStaticProps.js

I'm not 100% sold on that approach because I wouldn't necessarily look in src/screens for functions that handle HTTP requests. The project workflow and subject set pages also don't have components under src/screens, since they re-use ClassifyPage. Neither of those are big problems, in my mind. We could export src/screens/ProjectHomePage/getServerSideProps from pages/project/[owner]/[project]/index and src/screens/ClassifyPage/getServerSideProps from every page under pages/project/[owner]/[project]/classify

I ended up copying the tests for getServerSideProps from the tests for fetchWorkflowsHelper, so there’s a lot of overlap between those specs.

I've done some reading up on server-side errors in NextJS. I think we have two choices.

1. Any uncaught error in getServerSideProps returns a 500 response and the app's error page. The default error page is a blank page saying 'An unexpected error has occurred' (see the screenshot in Project: client-side page data requests (/_next/data/ URLs) broken #1826.) NextJS recommends letting Next handle your server-side errors and set up a custom error page. This seems like the appropriate response, to me, if Panoptes is down.
2. We wrap getServerSideProps in try… catch and return some default set of props in case of an error. In this case we'd send back a 200 response along with a page that includes an error message. That makes me slightly nervous because a 200 response can be cached by the browser and might not refresh immediately on page reload.

EDIT: 200 responses can be indexed by search engines too.

In #1964 I’ve figured how to customise the error message. I haven’t experimented much with it, but that might work for 500 errors too.

One thing I haven’t figured out: how to add tests to pages. Every JS file under /pages is a page on the site. Right now, my approach to that is to imported helpers, which have tests, and run those in getServerSideProps.

This might work. Put the page tests in /src/tests. https://medium.com/frontend-digest/testing-getserversideprops-in-nextjs-b339ebcf3401